Here we can take the chance to mention in the documentation (at least in the docstring) is that when a BuiltinRule (FunctionApplyRule) is applied, the "match" status of the rule depends on the return value of the applied function.

For example, suppose that we try to apply the "standard" F[x_]->x^2 to the expression F[2]: Then, the pattern "matches" with the expression, Blank[x] is replaced by 2 and the new expression 2^2 is obtained. At this point, the evaluation method stops looking for other rules to be applied over F[2].

On the other hand, suppose that we define a FunctionApplyRule that associates F[x_] with the function

def eval_f(x, evaluation):
   "F[x_]"
    if x>3:
        return Expression(SymbolPower, x, Integer2)
   return None

Then, if we apply the rule to F[2], the function is evaluated with None as its result. Then, in the evaluation loop, we get the same effect as the pattern didn't match with the expression: the loop continues then with the next rule associated to F.

Why do we have this behavior?

Because sometimes, the cost of deciding if the rule match is similar to the cost of evaluating the function. Suppose for example a rule

F[x_/;(G[x]>0)]:=G[x]

with G[x] a computationally expensive function. To decide if G[x] is larger than 0, we need to evaluate it, and once we have evaluated it, just need to return its value.

Also, this allows us to handle several rules in the same function, without relying on our very slow pattern-matching routines, in particular, for some "critical" low-level tasks like building lists in iterators, processing arithmetic expressions, plotting functions, or evaluating derivatives and integrals.

Good! I will mention this both as a docstring and add it to the developers guide.